Transit processing is similar to highway-network processing, but more complex. During transit processing, the program must form a transit network and develop paths between zones. The program uses paths to extract level-of-service (LOS) data, which mode- choice models use (in a separate process). The program also uses paths to assign trips to the network. When developing paths for transit processing, the program must consider mode transfers, mode weighting, and line combinations—a more complex process than path development for highway processing.

A transit network contains lines and support links. Lines are user- defined transit routes. Support links—nontransit links that provide connectivity between different transit lines and between zone centroids and lines—are necessary to support the transit system. Types of support links include walk, park-and-ride, and transfer. The program requires a background highway network as the starting point for support links and lines. The highway network provides the location of nodes, and basic information about distance and highway travel. For transit lines that do not use separate guideways, such as buses, the program computes the line’s speed as some function of the highway distances and speeds on the links used.

Every support link and every transit line must have a mode number. Mode numbers can range from 1 to 255. The program treats modes assigned to transit lines as transit modes and treats all other modes as support modes. You may assign mode numbers as desired, but if the program detects any support links with a mode used by a transit line, the program will terminate with a fatal error message. Bentley recommends that you set a standard for defining modes and use that standard consistently.

Support links can use the distances from any related highway links, but usually the program computes support-link travel times with a separate process. You must enter support links with control statements. Traditionally, the program uses support links to model people walking to, from, and between transit stop nodes, and for driving from zones to transit. TRNBUIILD has no predefined specifications of support links and their modes. For maximum flexibility, Bentley recommends assigning separate modes for the following categories:

• Walk from zone to another mode

• Walk to zone from another mode

• Drive from zone to another mode

• General walking

You might prefer to funnel all access to and from rail stations through links of certain modes (usually walk, transit, and drive). This requires saving three modes for these access links. You might prefer to further stratify transit access by grouping some transit modes.

With properly structured data, you can easily change mode assignment. When defining support links, you can assign modes. TRNBUILD allows you to assign a global value for modes, and to change the global setting before reading various line records. However, global values are not compatible with transit-network editing in CUBE Base. Therefore, Bentley recommends that you not use global values.

The program has a built-in process to generate zonal access support links automatically. That process builds traditional paths using the highway-link distances and the walk speed to find the best path from each of the selected zone centroids to each of the transit stops within a designated distance. The program generates a support link from the zone to each stop reached within the specified distance. You can vary the distance by mode, and can limit the number of links by mode. The program can generate links from a zone, to a zone, or from a zone and to a zone. The program assigns modes globally. If the program uses a special highway network, you can also restrict the number of highway links that paths traverse. You can also provide access links that cause the program to develop the path from the zone to the link’s A-node, rather than from the zone to a stop node at the link’s B-node. You must initiate zonal access with the ZONEACCESS control statement.

PNR control statements trigger a similar built-in process to generate drive-access support links. PNR access development differs from zonal access development. If you code PNR node as a link, the program considers the first node to be the PNR node, and generates an additional lot link between the two nodes. Only the zones explicitly defined with the PNR node can access the node. The program will generate an access link from each specified zone that is within the specified distance of the PNR node. You can enter the generated links as either one- or two-way; usually you will code drive-access links as one-way. The program develops the zone-to- PNR-node link using a minimum-time path-development process. These processes only use the links in the highway network. Specifying the maximum-time parameter can reduce the path development time. You cannot suppress this access development process if there are PNR control statements in the input.

Path Building

The program builds transit paths using a special algorithm, which is similar to highway path building. When building highway paths, the program develops a path set for an origin zone, and then extracts individual zone-to-zone paths. Transit path building has considerably more variables than traditional highway path building. Rather than simply developing the single best path between two zones, TRNBUILD allows you to invoke many factors at various points in the process.

The algorithm determines the best path to each node. Because there may be restrictions (usually mode oriented) out of the node, the program must keep the best path into each node for each active mode at the node. This requires considerable computer resources. Though the algorithm can develop paths by saving just the single best path into a node, this method may not obtain true minimum paths if there are mode-change factors or prohibitions. Saving the single best path will reduce path-development time by about sixty percent. The PATHSTYLE parameter sets the alternate option (see PARAMETERS).

Usually, you input transit-line data in some period-specific basis, which may be inconsistent with the processed period. For example, you might include a line with a 90-minute headway in an analysis for a 60-minute period. Because the program is not time specific, the program does not know how many times the line is available at a particular stop node during the process: one time or two times? Instead, the program assumes that any line is available at any of its stop nodes.

Traditionally, a line’s wait time is calculated as one-half of its headway. However, most travelers are somewhat knowledgeable about what time they can board the line. Therefore, you might invoke a maximum initial wait time, IWAITMAX. For example, a 60- minute line would normally have a 30-minute wait time. But when the line is the first in a trip, you might cap the wait time. To ensure that wait time accounts for boarding time, you can also set a minimum wait time, IWAITMIN. Similarly, for transferring passengers, the transit system likely offers some synchronization and the wait time may differ from the traditional wait time. You can specify maximum and minimum wait times at transfer points with XWAITMAX and XWAITMIN.

TRNBUILD also allows you to factor times on various segments of a trip, creating perceived times that differ from actual times. The program applies these perceived factors based on modes, wait time, and transfers. The program builds paths based on perceived times. Before choosing a path segment, the program converts the actual time to perceived time based on the action considered. As the path moves from one segment to another, the modes of the from- and to-segments determine how the program processes the path. The program considers a segment to be either a support link or a contiguous portion of a transit line. In most cases, segment connections have some associated perceived time. Boardings occur when accessing a transit segment; transfers occur at any boarding other than a path’s initial boarding.

During segment-to-segment processing, the program adds a value to the path time; it can be zero. The program obtains the added value from the XPEN and XPENFAC arrays, depending upon the segment modes (see FACTOR). The program considers the XPEN value to be an actual value, which is modified during path selection by the XPENFAC factor to obtain a perceived value. The values are mode-to-mode specific, and include all modes. You can prevent certain mode-to-mode combinations with NOX factor switches. The program computes the perceived segment time by multiplying the actual segment time by the segment’s MODEFAC factor. If the to-segment is transit, the program also multiplies the wait time by the XWAITFAC factor and possibly adds a boarding penalty, BOARDPEN. You can use the boarding penalty to add larger perceived values to the path time as the number of boardings increases, discouraging excessive transit boardings.

In basic mode, the program works with only the set of best paths between two zones (I-J). For some zone combinations, there are other reasonable possibilities. However, considering all possibilities would take an inordinate amount of computer resources. TRNBUILD has an option to calculate additional path sets based on the accesses at the zones. Specify this option with a MULTIACCESS control statement. With this option, the program builds a path set from every outbound link at zone I and considers all the access links at J for each path to J. Thus, if zone I has four outbound links and zone J has four inbound links, the program might consider up to sixteen paths between I and J. During assignment, the program compares each of the I-J possibilities to the best path between the zones, and considers only those that fall within the MULTIACCESS specifications. Those specifications define time differences, specified as both actual minutes and relative time. For example, if MULTIACCESS MAXTIMEDIFF=3, MAXPCTDIFF=10, then the assignment program will use any I-J path that is within 3 minutes, or 10 percent, of the best I-J path.

The program uses all the selected paths in assignment. The program allocates trips to the paths according to the relative times of the paths. Specifying MULTIACCESS for an application without assignment has no effect on results. However, if an application traces paths, the trace will show the various paths that would be used during assignment. Note that the multiaccess process does not necessarily create a good spread for the assignment. The spread depends on the access links at a zone. For example, if three outbound access links connect to the same line, the spread may be only between the access links. If there is another access link to another line, that link might get a smaller share because the program spreads the trips across the four links. The multiaccess process increases path-building time because the process must build more paths.

TRNBUILD line-combining process

The line-combining process selects the path from a node when travelers can choose from more than one line to reach a specific downstream node. TRNBUILD’s line-combining process combines only lines with the same mode.

When there are several lines of the same mode that can take a passenger from a particular node to the same downstream node and those lines have different headways or different run times, TRNBUILD considers perceived times and completes the following steps:

1. Select the best line, based on the total time (sum of wait time and run time) between the two points on each line.

2. Save lines that have a total time within the mode’s COMBINE criteria.

3. Compute combined wait time by dividing the total number of vehicles available per hour into sixty minutes, and dividing by two.

In many cases, the run times for the lines vary, so a method must be employed to compute a weight for each line’s run time.

It would seem that the average run time could be used, but there are scenarios where this could result in rather strange values. A typical scenario would be at a station where there are numerous local lines (low headways) that run at slow speeds, and an occasional express line (high headway) that runs at a high speed.

A new wait time is computed for each line by subtracting the best run time from the line’s total time. These new wait times are used to compute an equivalent headway, which in turn, is used to compute an estimated combined wait time. Each line’s run time is given a weight based upon the ratio of the estimated wait time to its new wait time. The total run time is weighted sum of all the line run times.

There is no guarantee that the process will always result in a combined total time that is less than the best path for every situation. But, the process is reasonable in most situations.

To illustrate the process, define the following terms:

• Actual value (A) — Determine directly from line links and frequencies (that is, the actual link time or the actual waiting time to board).

• Perceived value (P) — Compute by factoring actual value by an appropriate weighting factor

• Arun — Actual run time

• Await — Actual wait time (headway/2). This value is restricted by the wait factors (IWAITMIN, IWAITMAX, XWAITMIN, and XWAITMAX)

• Prun — Perceived run time (Arun * ModeFac)

• Pwait — Perceived wait time (Await * WaitFac)

• Ptt — Perceived travel time (Prun + Pwait)

• B(arg) — Best value of arg

A list of all the lines and their corresponding Ptt to reach the node from this node is obtained. The line with the lowest Ptt is considered as the best line. All other lines are then evaluated to determine if they should be combined with the best line. A line will be combined with the best line if its Ptt does not exceed the sum of the B(Ptt) + MaxDiff, or, if there is a COMBINE IF expression which is satisfied for the line.

After the program obtains a list of the lines to be combined, it determines how the trips will be distributed among the lines. A revised perceived wait time for each line is computed as the difference between the line’s Ptt and the B(Prun). Each line is given a weight based upon its revised wait time relative to the other lines’ revised wait times.

The perceived path wait time is computed as one half the headway based upon vehicles available and factored by the appropriate wait factor. ( (60 / VehAvail / 2) * WAITFAC). The perceived path run time is the sum of (weight * perceived run time) for all lines.

Example: Assume the following conditions for an initial boarding between a node pair, and MaxDiff = 10.00:

IWAITMAX=8 IWAITMIN=2 MODEFAC=1.2 IWAITFAC=2.5
Line Freq Run Pwait Prun Ett RWait Wt Rtime
A 10 22 12.50 26.40 38.90 26.90 .291 7.69
B 15 15 18.75 18.00 36.75 24.75 .317 5.70
C 20 10 20.00 12.00 32.00 20.00 .392 4.70
D 60 23 20.00 27.60 47.60 Not combined

Perceived Path Values: Wait= 5.45 Rtime= 18.09

Trip matrix processing

TRNBUILD can assign trips from a trip matrix to the paths. When using a trip matrix, the program does not build path sets for origin zones without trips. This can reduce computation time considerably. If there are any trips for any of the I-J pairs selected (explicitly or implicitly), the program generates the path set, but only processes the selected I-J pairs with trips. If the assignment option is true, the program assigns trips to the appropriate I-J paths. The program accumulates link volumes and node boardings and exits. You can requests several types of reports showing assignment results.

See FILEI

Level-of-service extraction

You can obtain zone-to-zone values for various elements of the I-J paths. These elements include times, distance, first and last transit nodes, access and first transit modes, number-of-boardings, and fares. You can extract most elements by mode, or combinations of modes. You can combine elements with user expressions. If the program traces an I-J pair, the trace includes a list of its basic elements. The transit running times and distances may be not exact for the transit legs where the path is split amongst several lines. In those segments, the extracted element is the sum of (line weight * network value) for all lines in the segment.

See FILEO.

If the you specify the FILEO MATO keyword, the program writes the extracted values in matrix format to the specified file. See also MULTIACCESS.

Output network

This version of TRNBUILD does not write an explicit transit network. The program can write a DBF file containing the nodes and links, and you can use the file with CUBE Base.

You can reduce the number of links in the output file by restricting the modes to be included. The TRNBUILD network will automatically include all the nodes in a transit line. However, an option lets you restrict the output to only stop-to-stop links (omitting the intermediate non-stop nodes). If an assignment is made, the file will contain link volumes, boardings, and exits at each link’s nodes. See also FILEO.